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Remarks 

The Applicant respectfully requests reconsideration and reexamination of the 
above-identified patent application, without amendment. Claims 1-42 are pending in this 
application. Of the pending claims, claims 1,15, 29, and 33 are independent claims. 

Claim Rejections - 35 U.S. C S 103 

In the final Office Action mailed November 14, 2006, the Examiner rejected 
claims 1-42 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,477,627 
issued to Ofek ("Ofek"). The Applicant respectfiilly traverses. 

1. Independent Claiin 1 

Independent claim 1, which is representative of independent claims 15, 29, and 
33 for pxirposes of distinguishing over Ofek, recites a method for synchronizing transactions. 
The method includes specifying an adjustable synchronicity setting indicative of an acceptable 
amount of lag for a second computing entity to lag behind a first computing entity in executing 
commands. A lag between the entities is controlled by executing commands at the first entity 
until the synchronicity setting is reached. The commands executed at the first entity are 
relayed to the second entity for the second entity to execute. The method fiirther includes 
postponing executing additional commands at the first entity and postponing relaying the 
additional commands to the second entity while the synchronicity setting is reached until the 
second entity has executed at least some of the relayed commands and lags behind the first 
entity by an amoxmt of lag that is no greater than the specified synchronicity setting. 

2. F.yamine r^s Position Regarding Ofek 

Regarding independent claim 1, the Examiner posited Ofek teaches a method 
for synchronizing transactions comprising: 
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Specifying an adjustable synchronicity setting indicative of an acceptable amount 
of lag for a second entity to lag behind a first entity in executing commands (citing col. 9, lines 
12-29 and 37-38); 

controlling a level of lag between the entities by executing commands at the first 
entity imtil the synchronicity setting is reached (citing col. 9, lines 31-33); 

relaying the commands executed at the first entity to the second entity for the 
second entity to execute (citing col. 9, lines 34-37); and 

postponing executing additional commands at the first entity and postponing 
relaying the additional conmiands to the second entity while the synchronicity setting is reached 
until the second entity has executed at least some of the relayed commands and lags behind the 
first entity by an amount of lag specified by the synchronicity setting (citing col. 5, line 66 — 
col. 6, line 14; col. 6, lines 27-31; col. 7, lines 9-15; and col. 9, lines 31-44). 

The Examiner posited Ofek teaches an adaptive copy mode in which writing 
between local and remote storage is "out of synchronism" by a specified limit (lag); and if the 
lag is exceeded during write operations, tiie system reverts back to the normal synchronism 
(SYNC) mode which postpones any fiirther write requests to the local storage imtil the remote 
storage returns an acknowledgment. 

The Examiner posited although Ofek teaches the limit can be exceeded, as soon 
as the limit is exceeded, the system enters the SYNC mode to maintain the specified lag. To 
clarify this teaching of Ofek, the Examiner provided an example in which the specified lag is 
the value of "10". In this example, the Examiner indicated once the lag value reaches "11" 
the Ofek system immediately enters the SYNC mode. The Examiner noted in Ofek, when a 
write request after the lag value has been exceeded, the write is not performed but rather the 
local storage sends a non-immediate retry message to try the write again at a later time (citing 
col. 7, lines 9-15). 

The Examiner took official notice it is notorioxisly well-known in the art that 
systems can be designed to perform an action once a linadt has been reached as opposed to when 
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a limit has been exceeded and thus interpreted as being obvious variations of one another and 
therefore obvious by design choice to implement either means within the Ofek system. The 
Examiner provided two examples of simple programming routines to illustrate the point that 
performing an action once a limit has been reached and performing an action until a limit has 
been exceeded are obvious variants from one another. The former routine illustrated how an 
action is stopped once the lag value reaches "10" when the specified lag value is "10"; and the 
latter routine illustrated how an action is stopped once the lag value reaches "11" when the 
specified lag value is "10". 

3. Independ ent Claim 1 Compared to Ofek 

Independent claim 1 generally differs from Ofek in that lag between first and 
second entities is controlled by executing conmiands at the first entity imtil a synchronicity 
setting indicative of an acceptable amount of lag for the second entity to lag behind the first 
entity in executing commands is reached and, while the synchronicity setting is reached, the 
steps of executing additional commands at the first entity and relaying the additional commands 
to the second entity are pos^oned until the second entity has executed some of the relayed 
conmiands and lags behind the first entity by an amount of lag that is no greater tiian the 
synchronicity setting. 

Assimiing for comparison with Ofek the commands are write requests and the 
synchronicity setting is indicative ov a maximimi number of write requests executed by the first 
entity and which are pending for the second entity to execute, independent claim 1 recites the 
first entity postpones executing additional write requests until the second entity has executed 
some of the pending write requests and lags behind the first entity by a number of pending 
write requests less than the maximum number. Likewise, independent claim 1 recites the first 
entity executes write requests up to the maximum number of write requests and does not 
execute additional write requests while the set of write requests executed by the first entity are 
pending for the second entity to execute. 
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In contrast, Ofek discloses the local storage (i. e. , the first entity) and the remote 
storage (i.e., the second entity) may be in a state in which the remote storage lags behind the 
local storage in executing write requests by an amount of pending write requests greater than 
the maximum nimiber (i. e. , Ofek discloses the remote storage may lag behind the local storage 
by an amovmt of lag greater than the synchronicity setting). (See, for example, col. 6, lines 
22-27 and coL 8, lines 45-61 of Ofek.) For this situation in which the number of pending 
write requests for the remote storage is greater than the maximum number (i.e., the 
synchronicity setting) to occur, the local storage has to have executed a number of write 
requests greater than the maximum number before the remote storage has executed any of these 
write requests executed by the local storage. 

In independent claim 1, the situation in which the number of pending write 
requests for the second entity is greater than the synchronicity setting does not occur as the 
first entity postpones executing additional write requests while the synchronicity setting is 
reached (i.e., while the number of pending write requests for the second entity matches the 
maximum number). This ensures that at all times the second entity lags behind the first entity 
in executing write requests up to a maximimi nimiber of pending write requests. In contrast, 
the Ofek system is configured such that the remote storage (i.e., the second entity) will 
sometimes lag the local storage (i.e., the first entity) in executing write requests more than a 
maximum number of pending write requests. 

As indicated above, the Examiner acknowledged that in the Ofek system the lag 
limit of write requests between the two entities can be exceeded. However, the Examiner 
posited that as soon as the linut is exceeded, the Ofek system reverts back to a SYNC mode 
in which fiirther write requests are postponed until the lag between the entities falls under the 
limit in order to maintain the specified lag. The Exanwner indicated performing an action until 
a limit has been reached and performing an action until a limit has been exceeded are obvious 
variants fi-om one another. To this end, the Examiner indicated that (a) stopping write requests 
once the lag value reaches "10" when the lag limit is "10" is the same as (b) stopping write 
requests once the lag value reaches "11" when the lag limit is " 1 0" . The Examiner posited the 
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characterization "a" corresponds to independent claim 1 and the characterization "b" 
corresponds to Ofek and that such characterizations are obvious variants from one another. 

However, Ofek does not teach or suggest a scenario when the lag value would 
be " 1 1 " in this example. In contrast, Ofek suggest that the lag value is much higher. That is, 
Ofek suggests that the remote storage lags the local storage in performing write requests by a 
number of write requests which is much greater than the difference between one additional 
write request (e. g. , "11") and the lag limit of write requests (e. g. , " 1 0"). This is evident as 
Ofek discloses that the lag limit between the local and remote storage is exceeded during 
"bursts of writing operations" and "block transfers" (see col. 2, lines 14-55 of Ofek). Such 
operations entail the remote storage lagging the local storage by significantly more than one 
writing action. As such, Ofek does not teach or suggest controlling lag between two entities 
such that one entity lags behind the other entity by an amoxmt of lag that is no greater than a 
specified amount of lag as claimed. 

Further, the Examiner noted in Ofek, when a write request after the lag value 
has been exceeded, the write is not performed but rather the local storage sends a non- 
immediate retry message to try the write again at a later time (citing col. 7, lines 9-15). Col. 
7, lines 9-15 of Ofek refer to the SYNC mode of operation and does not refer to the mode of 
operation in which the remote storage lags behind the local storage by more than a specified 
amoimt of lag. 

In view of the foregoing remarks, independent claims 1, 15, 29, and 33 are 
patentable over Ofek. Claims 2-14, 16-28, 30-32, and 34-42 depend from one of the 
independent claims and include the limitations of their respective ind^endent claim. 
Accordingly, the Applicant respectfiilly requests reconsideration and withdrawal of the 
rejection to claims 1-42 xinder 35 U.S.C. § 103(a). 



S/N: 10/026,547 

Response to final Office Action of November 14, 2006 



Atty Dkt No. 2001-087.ICE (STK 01087 PUS) 



CONCLUSION 



In sxmunary, claims 1-42 meet the substantive requirements for patentability. 



The case is in appropriate condition for allowance. Accordingly, such action is respectfully 



If a telephone or video conference would expedite allowance or resolve any 



further questions, such a conference is invited at the convenience of the Examiner. 



Date: November 29. 2006 

BROOKS KUSHMAN P.C. 
1000 Town Center, 22nd Floor 
Southfield, MI 48075-1238 
Phone: 248-358-4400 
Fax: 248-358-3351 



requested. 




Respectfully submitted. 



